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Abstract — Cisco Systems and NASA have been performing joint research on mobile routing technology under a 
NASA Space Act Agreement. Cisco developed mobile router (MR) technology and provided that technology to 
NASA for applications to aeronautic and space-based missions. NASA has performed stringent performance testing 
of the MR, including the interaction of routing and transport-level protocols. This paper describes mobile routing, 
the MR, and some key configuration parameters. In addition, the paper describes the mobile routing test network 
and test results documenting the performance of transport protocols in dynamic routing environments. 

1 . Introduction 

Cisco Systems and NASA Glenn Research Center have been performing joint networking research under a NASA 
Space Act Agreement to apply Internet technologies and protocols to aeronautic and space-based communications. 
Cisco Systems developed the mobile router (MR) during this time and provided the technology for both the 
commercial and government markets. The technology was given to NASA for evaluation of its applicability to 
NASA’s aeronautic and space-based networks. By performing joint testing of the MR, NASA was able to provide 
input about applications and requirements. Cisco was then able to modify the code where appropriate to address 
those needs and requirements. This paper will describe mobile routing, the MR and some key configuration 
parameters, the test network, and the performance of transport protocols in dynamic routing environments. 

2. Mobile IP Overview 

Mobile IP (ref. 1) is a routing protocol that allows hosts (and networks) to seamlessly "roam” among various 
IP subnetworks. This is essential in many wireless networks. Mobile IP can also be useful in wireless networks 
where the MN’s point of attachment to the network changes due to varying conditions in the wireless medium, even 
if the MN is not physically moving. In a wired network, mobile IP can be used where the MN simply wishes to 
maintain its network identity, since the MN is always contacted through association of its home IP address. 
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There are three basic elements in the mobile IP; the home agent (HA), the foreign agent (FA), and the mobile node 
(MN). 

“The Home-agent (HA) is a router on a mobile node's home network that tunnels datagrams for delivery to the 
mobile node when it is away from home, and maintains current location information for the mobile node. The 
home-agent is the mobile node's gateway to the network. All traffic destined for the mobile node must pass 
through the home-agent. 

“The Foreign-agent (FA) is a router on a remote network that provides routing services to a registered mobile 
node. The foreign-agent receives datagrams from the home-agent via an IP tunnel, which are then forwarded 
to the mobile node. For datagrams sent by a registered mobile node, the foreign-agent serves as a default 
router. 

“The Mobile-node (MN) is a host or router that changes its point of attachment from one network or 
subnetwork to another. A mobile node may change its location without changing its IP address; it may 
continue to communicate with other Internet nodes at any location using its (constant) IP address, assuming 
link-layer connectivity to a point of attachment is available.” (ref. I ) 

An MN first determines whether it is attached to its home network or a foreign network using Internet control 
message protocol (ICMP) router discover messages. If it is attached to a foreign network, the MN will determine if 
an FA is available. If so, the MN registers with the HA via the FA, and a unidirectional IP tunnel 1 is established 
from the HA to the FA. The HA will now encapsulate all packets destined for the MN and tunnel them to the FA. 
The FA de-encapsulates the packets and forwards them on to the MN. Standard IP routing is used to deliver 
datagrams sent by the MN, with the FA as the MN's default router. 


Mobile node 



Figure 1. Mobile IP Tunneling 


Figure 1 depicts mobile-IP operation when the MN is a single host. In this scenario, the corresponding node requests 
information from the MN. The request is sent first to the MN's home IP address via the Internet. Thus, the request 
goes to the HA. The HA encapsulates the request in a second IP packet and tunnels that request through the Internet 
to the FA. The FA de-encapsulates the request and passes it on to the MN via the care-of address 2 (COA). Once the 
MN receives the request, it sends a reply to the corresponding node through normal IP routing. Thus, the reply goes 
to the FA, which passes it on to the corresponding node via the Internet. 


Tunneling is a technique that enables one network to send its data via another network's connections. Tunneling works by encapsulating a 
network protocol within packets carried by the second network. 

" It is also possible to have a collocated COA. In the case of a collocated COA, the HA encapsulates packets directly to the MN instead of 
to the FA. 
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3. Mobile Router Overview 

The MR is software code that resides in a network router. It is part of the mobile IP standards specification. An MR 
allows entire network(s) to roam. Hence, a device connected to the MR does not need to be an MN because the 
MR is providing the roaming capabilities. 

Cisco Systems has recently implemented MR code. NASA Glenn and Cisco, through a Space Act Agreement, have 
been performing joint research and validation tests on this code, which became part of the Cisco Systems 
Internetworking Operating System (IOS) in the second half of 2000. The MR is currently being deployed for a static 
network, which only supports stub routers. Future implementations will support dynamic networks. 

MR code allows a router to be an MN. The difference between a mobile host and an MR is that once the MR has 
registered with the HA, the HA will inject the MR’s networks into the HA's routing table and redistribute these 
routes. This implementation is fully compliant to the RFC 2002 standard. No alteration to the specification is 
necessary to achieve this static networking. 

Figure 2 depicts mobile-lP operation when the MN is a network. The operation is nearly identical to that of a mobile 
IP for a single host. The exceptions are that two tunnels are established: one between the HA and FA (Tunnel 1), and 
one between the HA and MR (TunnelO). The HA will perform two encapsulations of any packet destined for the MR 
and forward all packets for the mobile network to the FA. The FA will perform one de-encapsulation and pass the 
packets to the MR. The MR performs the second de-encapsulation and forwards the packets to the devices on its 
networks. As the MR moves, it will register its whereabouts with its HA via various FA's. Thus, an MR is an MN; 
however, the node is a network rather than a single host. 

The MR has a number of features that make it applicable to a variety of networks and applications. 

• The MR can have multiple roaming interfaces. This allows for connection to a variety of different wired 
and wireless links. 

• The MR can perform smooth handoffs, preferred path routing, and priority routing. 

• The HA can be configured for hot-standby. This is extremely important. If the HA were to experience a 

catastrophic failure, all routes would be lost. Hot-standby was demonstrated by pulling the power plug on 
the active HA and noting restoration time. Restoration was nearly instantaneous. 

• The mobile routing protocols perform well in long delay environments. Testing of the MR capabilities over 

links with round-trip time delays in excess of 3 sec was performed. This delay is far greater than a double 
geostationary satellite hop. 



Figure 2. Mobile Router Tunneling 
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As of April 2001, Internet protocol security (IPSec) 3 between the FA and MR, multicasting, and unidirectional link 
routing (UDLR) 4 were still being addressed. Currently, security between the MR and HA is performed using the 
128-bit message digest algorithm (MD5). Security can also be implemented between the FA and HA via IPSec 
and/or by the establishment of access lists in the HA. 

4. Mobile Routing Operations 
4. 1 Agent Discovery 

Agent discovery is a key function of mobile routing, both for mobile hosts and MR’s. For many network 
architectures that utilize MR’s, optimal configuration of agent discovery and advertisement could result in improved 
system performance or lower communication costs. Therefore, agent discovery will be discussed in detail here. 
Issues include 

• Speed of FA discovery (initial registration) 

• Who pays for the Wide-Area Network (WAN) RF bandwidth 

• Cost of RF bandwidth 

System performance and communication cost optimization is performed by adjustment of various timers in the MR 
and FA, as well as by enabling or disabling FA advertisements and MR solicitations. Having the MR periodically 
solicitate or decreasing the interval between the FA advertisments will speed up FA discovery at the expense of 
increased bandwidth utilization. This may not be desirable for expensive or bandwidth-limited wireless connections. 
Thus, great care should be utilized when configuring the mobile network. 

An MR discovers an FA by receiving agent advertisements on its interfaces configured for roaming. Agent 
solicitation may also be configured on an MR interface that does not expect periodic agent advertisements from 
FA’s. 

An MR will send out agent solicitations to find FA's 

• If the interface is configured for roaming 

• If the MR’s roaming interface comes up 

• If there is a retransmission after no advertisement is heard 

• Before advertisement expiration 

A table of available FA’s and their associated COA’s are derived from agent advertisements heard on the MR’s 
roaming interfaces. The MR then registers with the HA through one of the FA’s listed in this table. The FA that the 
MR selects is known as the active FA, and the MR’s connection to the active FA is known as the preferred path. 

The selection of the active FA and preferred path is based on the MR’s roaming interfaces. If more than one 
interface receives agent advertisements, the one with the higher roaming priority value is selected as active. If 
multiple interfaces have the same priority, the highest bandwidth is active. If interfaces have the same bandwidth, 
the highest IP address is active. The MR will then send a registration request bound for the HA to the active FA via 
the preferred path. 

A learned FA entry is removed from the table when 

• An unsolicited interface’s advertisement ages out 

• Solicitation retransmissions max out 

• Roaming on the interface is deconfigured 

• Registration via an active FA to the HA ages out 


3 The IPSec protocol provides secure, interoperable communication across a network, transparent to the application. 

UDLR is a mechanism to emulate bidirectional connectivity between nodes that are directly connected by a unidirectional link. 
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• Unrecoverable registration denials are received from HA 

• The MR is disabled 

• The interface where the FA was learned goes down 

• The user manually clears FA via the command line interface 

There are a variety of timers available to optimize network performance. There are three timers in the MR: agent 
solicitation, agent advertisement, and registration. The agent solicitation tinier is for periodic transmission of 
solicitations generated by the MR. The agent advertisement timer is for aging out received advertisements from an 
FA. Both the agent solicitation and agent advertisement timers are used as watchdog timers for the MR’s agent 
discovery of an FA. The registration timer is for periodic transmission of registration requests to the HA and is used 
as a watchdog timer for the registration between the HA and the MR. There are timers within the FA to control the 
FA advertisments. These timers are associated with the ICMP router discovery protocol (IRDP) configuration and 
include the minimum and maximum advertisement intervals and the holdtime, the time for which advertisements are 
valid. One timer is available on the HA to globally control the maximum valid registration lifetimes of mobile hosts. 
This timer may also be configured in the FA and MR, but the lifetime of the registration will be set to the lesser of 
the 3 time settings. 

4.2 Registration 

After determining the preferred path, the MR will send a registration request to the HA. Since the MR is attached to 
a foreign network, the registration request is sent first to the active FA, which then forwards the request to the HA. 
Registration requests are only sent out to an active FA. The following events will trigger a registration request: 

• If an FA advertisement is received from the MR and 

o Movement from one FA to another has been detected 
o An FA reboot has been detected 
o The MR is currently isolated 

o An advertisment has been received from another FA that is connecting via a better interface 
(preferred path) 

• If an active FA advertisement (IRDP lifetime) expires, and the MR chooses another learned FA to 
reregister through 

• If a registration timer expires due to retransmission or lifetime aging 

• If the hold-down period on the FA expires 

• If the interface connected to the active FA goes down, and there are other FA's 

• If the MR configuration changes 

• If the MR has to recover from HA denial due to mismatched ID 

• If the MR has to recover from FA denial due to low r er lifetime 

4.3 Key Configurations Parameters 

Figure 3 shows the detailed network configuration used to test the MR at NASA Glenn. We wall utilize this to 
describe the test network, as well as to help illustrate the configurations of the various mobile network routers: the 
HA, the FA, and the MR. 

4.3.1 Home Agent Configuration 

The following is a partial listing of the HA configuration highlighting key configuration parameters. 

A loopback interface is created for the HA network address. This is done so that any physical interface can go dowm 
without the HA being lost. The static routes and mobile subnetworks must be redistributed. This is done using the 
redistribute command in the router setup. The command “router mobile" enables the mobile-IP process on the 
router. 
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Figure 3. Mobile Router Test Network Configuration 


A static route has been established to enable routing from our unroutable network to the Glenn network via a linux 
workstation configured to forward packets. This enables us to route to the Internet for demonstrations but to 
disconnect for all other testing, thereby maintaining a secure network. 

The MR-specific configuration commands using the “IP mobile” commands. A virtual network is the first setup. 
Here the virtual network is 10.2.0.0. Next, the mobile networks are established. These are the loopback and physical 
interfaces on the MR. The mobile host is then defined as is the MD5 security association. 

Home agent "Tofo’o " routing configurations — partial listing 
| - 
interface LoopbackO 

I 

ip address 10.0.11.50 255.255.255.255 

i 

router mobile 

t 

router ospf 64 
redistribute static 
redistribute mobile subnets 
network 10.0.0.0 0.255.255.255 area 0 

t 

no ip classless 

ip route 139.88.0.0 255.255.0.0 10.0.7.2 
no ip http server 

ip mobile virtual-network 10.2.0.0 255.255.0.0 
ip mobile mobile -network SPACE 10.2.3.0 255.255.255.0 
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ip mobile mobile-network SPACE 10.2.52.0 255.255.255.0 
ip mobile mobile-network SPACE 10.2.4.0 255.255.255.0 
ip mobile mobile-network SPACE 10.2.10.0 255.255.255.0 
ip mobile mobile-network SPACE 10.2.19.0 255.255.255.0 

ip mobile host 10.2.10.100 mobile-network SPACE virtual -network 10.2.0.0 255.255.0.0 
ip mobile secure host 10.2. 10. 100 spi 500 key hex 123456781234567812345678 12345678 

T 

The routing tables, bindings, and tunnels for the HA are shown below. Note that all the networks on the MR are 
connected via Tunnel 1, whereas the address assigned to the MR (MN) is connected via TunnelO. The bindings show 
that the MR is bound to the HA through FA 10.0.8.22 and that the COA is 10.0.2.1. The bindings also show a 
registration lifetime of 35 sec. In this case, the lifetime count was taken from the MR because the MR requested 
lifetime is less than the HA default of 10 hr. 

Home asent “Tokyo ” diagnostic displays — select displays 

TOKYO#sho ip route 

Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP 
D - EIGRP, EX - E1GRP external, O - OSPF, IA - OSPF inter area 
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 
El - OSPF external type 1, E2 - OSPF external type 2, E - EGP 
i - IS-1S, LI - IS-IS level- 1, L2 - IS-IS level-2, ia - IS-IS inter area 
* - candidate default, U - per-user static route, o - ODR 
P - periodic downloaded static route 

Gateway of last resort is not set 

S 139.88.0.0/16 [1/0] via 10.0.7.2 

10.0.0.0/8 is variably subnetted, 14 subnets, 3 masks 
M 10.2.10.0/24 [3/1] via 10.2. 10.100, 3w5d, Tunnel 1 
C 10.0.8.0/24 is directly connected, FastEthemetl/0 
O 10.0.9.0/24 [110/85] via 10.0.8.25, 3w5d, FastEthemetl/0 
O 10.0.2.0/24 [110/2] via 10.0.8.22, 3w5d, FastEthemetl/0 
M 10.2.0.0/16 is directly connected 

M 10.2.3.0/24 [3/1] via 10.2.10.100, 3w5d, Tunnell 

M 10.2.4.0/24 [3/1] via 10.2.10.100, 3w5d, Tunnell 

C 10.0.7.0/24 is directly connected, FastEthernetl/1 

O 10.0.19.0/24 [1 10/75] via 10.0.8.25, 3w5d, FastEthemetl/0 
M 10.2.19.0/24 [3/1] via 10.2.10.100, 3w5d, Tunnell 
O 10.0.20.0/24 [1 10/65] via 10.0.8.25, 3w5d, FastEthemetl/0 
C 10.0. 1 1 .50/32 is directly connected, LoopbackO 
M 10.2.52.0/24 [3/1] via 10.2.10.100, 3w5d, Tunnell 
M 10.2.10.100/32 [3/1] via 10.0.2.1, 3w5d, TunnelO 

TOKYO#sho ip mobile tunnel 
Mobile Tunnels: 

TunnelO: 

src 10.0.11.50, dest 10.0.2.1 

encap IP/IP, mode reverse-allowed, tunnel-users 1 

IP MTU 1480 bytes 

Path MTU Discovery, mtu: 0, ager: 10 mins, expires: never 
outbound interface FastEthemetl/0 

HA created, fast switching enabled, ICMP unreachable enabled 
0 packets input, 0 bytes, 0 drops 
0 packets output, 0 bytes 


NAS A/TM— 2002-2 1 093 8 


7 


Tunnel 1 : 

src 10.0.11.50, dest 10.2.10.100 

encap IP/IP, mode reverse-allowed, tunnel-users 1 

IP MTU 1460 bytes 

Path MTU Discovery’, mtu: 0, ager: 10 mins, expires: never 
outbound interface TunnelO 

HA created, fast switching enabled, ICMP unreachable enabled 
0 packets input, 0 bytes, 0 drops 
0 packets output, 0 bytes 

Mobility Binding List: 

Total 1 

10 . 2 . 10 . 100 : 

Care-of Addr 10.0.2.1, Src Addr 10.0.8.22 
Lifetime granted 00:00:35 (35), remaining 00:00:20 
Flags sbdmgvt, Identification BDFEA1 12.4D61DAFC 
TunnelO src 10.0.1 1.50 dest 10.0.2.1 reverse-allowed 

MR TunnelO src 10.0. 1 1.50 dest 10.0.2.1 reverse-allowed mobile-network SPACE 
Routing Options - 

4.3.2 Foreign Agent Configuration 

The following is a partial listing of the configuration of one of the FA's (CLEVELAND), highlighting key 
configuration parameters. 

ICMP router discovery protocol (IRDP) must be running on the FA interfaces. Here, that interface is 10.0.2.1. 
For this configuration, the FA will advertise its services every 7 to 10 sec as defined by the minimum and maximum 
advertisement intervals. The IRDP holdtime indicates to the MR the period of time (in sec) that the FA's 
advertisement is valid. In the event that the MR does not receive an advertisement from the active FA before the 
holdtime timer expires, MR assumes that it is no longer on the active FA's network, and will attempt to re-register 
with an FA in its table. 

The mobile registration lifetime for the FA 10.0.2.1 is set for 40 sec. Setting the registration lifetime on the 
FA limits the maximum lifetime of registration that the FA will allow the MR to request from the HA. This 
parameter may also be configured in the HA and MR. However, the lifetime of the registration will be set to the 
shortest of the three time settings. 

As with the HA, the “router mobile" command must be issued to initiate the mobile-IP process. 

FA capability is initialized on each interface via the “IP mobile foreign-service" command. In our case, only 
interface 10.0.2.1 is acting as an FA. 

Foreign agent “ Cleveland " routing configurations — partial listing 

ip multicast-routing 

interface FastEthemet 1 /0 
ip address 10.0.2.1 255.255.255.0 
no ip redirects 
ip irdp 

ip irdp maxadvertinterval 10 
ip irdp minadvertinterval 7 
ip irdp holdtime 25 
ip mobile foreign-service 
ip mobile registration-lifetime 40 
no ip route-cache cef 
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no ip mro ute -cache 
full-duplex 

I 

interface FastEthemetl/1 
ip address 10.0.8.22 255.255.255.0 
ip pim dense-mode 
no ip route -cache cef 
no ip mroute-cache 
full-duplex 

t 

router mobile 
? 

router ospf 64 

network 10.0.0.0 0.255.255.255 area 0 

j 

no ip classless 
no ip http server 

ip mobile foreign-agent care -of FastEthernetl/0 

A listing of the FA visitors is shown below. There is only one visitor, the MR, as identified by the source address, 
10.2.10.100. The MR's registration lifetime with the FI A is 35 sec. 

Foreign agent “ Cleveland " diagnostic displays — select displays 

CLEVELAND#sho ip mobile visitor 
Mobile Visitor List: 

Total 1 

10 . 2 . 10 . 100 : 

Interface FastEthemetl/0, MAC addr 0002.4b47.7d70 
IP src 10.2.10.100, dest 10.0.2.1, UDP src port 434 
HA addr 10.0.1 1.50, Identification BE0006B8.B330DDD8 
Lifetime 00:00:35 (35) Remaining 00:00:22 
TunnelO src 10.0.2.1, dest 10.0.1 1.50, reverse-allowed 
Routing Options - 

4.3.3 Mobile Router Configuration 

The following is a partial listing of the MR configuration, highlighting key configuration parameters: 

As with the HA, a loopback interface is created for the MR network address. This is done so that any physical 
interface can go down without the entire MR being lost. 

The MR has four active physical interfaces. For the test network shown in figure 3, only the three Ethernet interfaces 
are being used. One of the Ethernet interfaces, FastEthemetO/O, is the LAN, while the other interfaces are configured 
as mobile interfaces that would connect to FA’s. This is defined with the “IP MR-service roam” command. Priorities 
can also be set for each roaming interface, thereby establishing preferred service paths. 

Routing protocols should be running on the MR if the MR ever plans to return home. When the MR is back home, it 
needs to propagate its mobile network to its HA using a routing protocol such as the open shortest path first (OSPF) 
or the routing information protocol (RIP). For this particular configuration, we are using OSPF. 

The “router mobile” command is issued to enable the mobile-IP process. 

The HA address has to be defined and proper security associations must be established between the HA and MR. 
This is accomplished with the “IP mobile secure home agent” command. 
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The "IP mobile router" command is used to enable the mobile routing functions, to set the address of the MR, and to 
set registration lifetimes and retransmission timers. 

Mobile router "MR " routing configurations — partial listing 

i 

interface LoopbackO 

ip address 1 0.2. 1 0. 1 00 255.255.255.0 

l 

interface FastEthemetO/O 
ip address 10.2.4. 100 255.255.255.0 
speed 100 
half-duplex 

I 

interface FastEthemetl/0 
ip address 10.2. 19. 100 255.255.255.0 
ip MR-service roam priority 163 
speed auto 
half-duplex 

I 

interface Serial2/0 

ip address 10.2.3.100 255.255.255.0 

ip MR-service roam priority 164 

! 

interface FastEthemet3/0 

ip address 10.2.52.100 255.255.255.0 

ip MR-service roam priority 1 65 

speed auto 

half-duplex 

I 

router mobile 

f 

router ospf 64 

network 10.0.0.0 0.255.255.255 area 51 

f 

ip classless 
no ip http server 

ip mobile secure home-agent 10.0.1 1.50 spi 500 key hex 12345678123456781234567812345678 
ip MR 

address 10.2.10.100 255.255.255.0 
register lifetime 35 
home-agent 10.0.11.50 

The routing table for the MR shows the physical interfaces as all directly connected. The FA 10.0.2.1 is the mobile 
connection and is set as the default router. Basically, the default router will always be the connection of the best 
available (preferred path) FA. 

There is currently only one FA registered with the MR. From the "show IP MR agent” command, we can see that 
the FA is 10.0.2.1 with a registration lifetime of 40 sec. 

Mobile router ‘MR " diagnostic displays — select displays 

Mobile-Router#sho ip route 

Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP 
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area 
N 1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 
El - OSPF external type 1, E2 - OSPF external type 2, E - EGP 
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i - IS-IS, LI - IS-IS level- 1, L2 - 1S-IS level-2, ia - IS-IS inter area 
* - candidate default, U - per-user static route, o - ODR 
P - periodic downloaded static route 

Gateway of last resort is 10.0.2. 1 to network 0.0. 0.0 

10.0.0.0/8 is variably subnetted, 5 subnets, 2 masks 
C 10.2.10.0/24 is directly connected, LoopbackO 
M 10.0.2.1/32 [3/1] via 10.0.2.1, 3w5d, FastEthemet3/0 
C 10.2.4.0/24 is directly connected, FastEthernetO/0 
C 10.2.19.0/24 is directly connected, FastEthernetl/0 

C 10.2.52.0/24 is directly connected, FastEthernet3/0 

M* 0.0.0.0/0 [3/1] via 10.0.2.1, 3w5d, FastEthemet3/0 


Mobile-Router#sho ip MR agent 

MR Agents: 

FA 10.0.2.1: 

Care-of address 10.0.2.1 

Interface FastEthemet3/0, MAC 0010.0b4a.7020 

Agent advertisement seq 26450, Flags rbhFmGvt, Lifetime 40 

IRDP advertisement lifetime 25, Remaining 22 

Last received 03/28/93 18:45:13 

First heard 03/02/93 03:32:55 

5. Test Network 

In order to test the MR in a relevant environment, a wired and wireless mobile testbed was developed at 
NASA Glenn. Figure 3 depicts the network configuration of that testbed. We have four mobile-IP-enabled routers: 
one HA, two FA’s, and one MR. Two additional routers, “homeboy” and “foreboy," reside between the FA wireless 
access point. These two routers are configured as bridges and are there simply to provide a serial interface for a 
satellite channel emulator. A linux workstation is connected to the HA and performs network address translator 
(NAT) functions in order to allow routing from the lO.x.x.x network to the NASA Glenn network. 

The satellite emulator is an Adtech SX/14 and provides both delay and error capability. We have used this unit in the 
MR testing to generate delay on the duplex path. 

The MR resides in a half-rack roll-around cabinet (fig. 4), which can be placed in the laboratory or on a van. The 
router is a Cisco 3640 with one four-port serial network interface card (NIC) and three Ethernet NIC’s. Connections 
can be wired or wireless while in the laboratory, and wireless via 802.1 1 wireless Ethernet connections when run in 
the van. The MR LAN also has wireless capabilities as well as a wired hub. Dynamic host control protocol (DHCP) 
is running on the MR LAN in order to easily add application and test computers to the network. An uninterruptible 
power supply (UPS) allows for up to 2 hr of mobile operation when no other power is available. In addition, the 
UPS cleans up the power provided by a diesel engine in the van. 

There are four wireless 802.11 WAN connections, two for each FA. One of the wireless connection antennas is 
located in the laboratory and is used when the MR is being tested there. Three wireless connections are placed on 
various buildings throughout the Glenn Research Center. One wireless antenna connects to the Cleveland FA. The 
other two antennas are connected to the Goddard FA and have the programmable delay unit in the path between the 
FA and the MR. All connections are fiber-repeated back to the laboratory in order to keep the IP traffic off the 
production network. However, the production network will be moved as soon as performance testing is complete. 
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Figure 5 shows a map of the antenna locations and a rough coverage map. The sites were picked such that we w ould 
have simultaneous coverage at some times, thereby enabling testing of smooth handoffs and preferred path 
operation. 

Figure 6 shows the various antennas deployed throughout the Glenn Research Center and on the MR test van. 
Dipole antennas are used on the buildings to provide circular coverage. Both yagi and dipoles are used on the van. 
Only one set is deployed at any one time. The yagis provide greater gain, but are directional. The yagi antennas 
enable us to test at farther distances if we wish, or to restrict coverage and force handoffs and loss of signal by 
positioning the yagi antenna away from the reciprocal signal. 



Figure 5. Wireless Ethernet Antenna Coverage 



Figure 6. Dipole and Yagi Deployment 
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6. Handoffs and Hold-Down Timers 


The MR only allows one active route between itself and the HA. Whenever two or more paths are available for 
routing data between an MR and an HA. only one is selected as the preferred path. If two or more paths are 
available, the preferred path always takes precedence. In a wireless network, there are situations where the 
nonpreferred path has significant RF signal strength, yet the preferred path has sufficient RF signal strength to 
register but be continuously fading in and out. This results in a "flapping interface,” whereby the MR is 
continuously setting up and tearing down routes to the preferred path as the RF signal fades in and out. The result is 
very poor data transfer, even though a strong signal and path is available from the nonpreferred path. In order to 
reduce this problem, a hold-down time is incorporated in the MR code and is set globally within the MR. The 
hold-down timer is used to establish a predefined amount of time that an interface must be stable before it is 
declared usable. In order to test the hold-down timer, we placed the van in a high-fade location. The preferred path 
had very little delay (10 to 40 msec) and 10 Mbps bandwidth. The nonpreferred path had 700 msec of delay and 
128 kbps of bandwidth. 

Figures 7 and 8 show a TCP transmission for the same amount of data with the hold-down timer set to zero and 
30 sec, respectively. In figure 7, the data is being transferred over the preferred path at all times, except during the 
initial 20 sec of transmission. The slope of the time/sequence plot shows this. The nontransfer time where the TCP 
retransmission timers begin is due to the flapping interface. Total transmission time when the hold-down timer was 
set to zero was approximately 5 min, even though the transmissions occurred almost exclusively over the 10 Mbps 
link. In figure 8, the hold-down timer was set to 30 sec. Nearly all the transmissions occurred over the 128-kbps, 
700-msec delay. Even with this lower bandwidth and additional delay, the same transmission only took a little over 
2 min. Approximately 30 sec into transmission, the preferred path became active and then lost the signal. Thus, the 
RF signal strength for the preferred path was sufficiently stable for at least 30 sec before fading. Flapping of the 
interface occurred, but the problem was significantly reduced. Increasing the hold-down time will improve the 
stability of the network. However, this also results in interfaces not being declared usable until the hold-down time 
expires. Thus, great care should be taken when setting this timer. 



Figure 7. TCP Transfer with Hold-Down Timer — 0 
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Figure 8. TCP Transfer with Hold-Down Timer = 30 sec 


7. Transport Protocol Performance 

We have demonstrated the MR functionality with live demonstrations. These live demonstrations validated the 
general mobile routing algorithms, including the preferred path. The MR was able to perform with round-trip time 
delays of up to 3 sec (1.5 sec in each link). Some of the applications we demonstrated included email transfers, Web 
browsing, voice-over IP (VOIP), ftp file transfers, secure shell, and Telnet. 

In order to access the system performance during handoff situations, a series of tests was developed to emulate two 
operational networks: a terrestrial wireless network and an aeronautical wireless network. The testbed show'n in 
figure 3 was used. The bandwidth on the preferred path was 10 Mbps and the bandwidth on the nonpreferred path 
was 128 kbps. The only difference between the wireless terrestrial network and the aeronautical network was the 
delay settings of the Adtech SX/14. For the wireless network, we used 100 msec round-trip times, and for the 
aeronautical network, we used 700 msec round-trip times. We use 100 msec as a reasonable estimate of terrestrial 
network delays through a wireless Internet sendee provider (ISP). The 700-msec round-trip time includes 500 msec 
for single-hop geostationary satellite round-trip delays and 200 msec for terrestrial round-trip delays. 

In order to isolate the handoff performance from other networking issues (congestion control, Quality-of-Service, 
etc.), data was taken for a single user emulation. The TCP implementations used were configured with fast 
retransmission, selective acknowledgement, and time-stamps options. The TCP performance tool ttep was used. 
TCP receiver and transmitter buffer sizes were set for 1 1 200 bytes, which is optimal for the bandwddth-delay 
product of the nonpreferred path at 700 msec delay. Packet size was 1400 bytes. The hold-down timer was set for 
30 sec. Tests were performed for both 100 and 700 msec delays while the MR transitioned between nonpreferred 
and preferred paths. Two ttep sessions were running simultaneously. The first had the source on the MR LAN and 
the destination on a LAN connected to an FA. The second had the source at the FA LAN and the destination on the 
MR LAN. 

Figures 9 and 10 show simultaneous TCP transmissions between a workstation on an FA LAN and a workstation on 
an MR LAN. The delay in the nonpreferred, 128-kbps path w r as set to 100 msec. Data w r as taken at the source of the 
TCP transmission. The workstation clocks were not synchronized; therefore, there is a slight offset in the timing 
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settings on the time-sequence plots. However, it is readily apparent that transmissions originating on the MR LAN 
and originating somewhere on the Internet have similar characteristics. During these transmissions, the van 
transitioned the network in the following manner: 


1 . Nonpreferred path 

2. Preferred path 

3. Nonpreferred path 

4. Preferred path 


sequence numbc ^Q 2.4 J6: 1081_==>_10.0^.7:500L (time sequence graph) 


3365000000 


3360000000 


3355000000 


3350000000 



15:32:00 15:34:00 15:36:00 15:38:00 15:40:00 

time 


Figure 9. Source: Mobile Router LAN 



time 


Figure 10. Destination: Mobile Router LAN 
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Figure 1 1 is a blown-up section of figure 10 from time 15:30 to 15:32. Figure 1 1 shows the smooth handoff from the 
128-kbps, 100-msec delay nonpreferred path to the 10-Mbps preferred path. Soon after utilizing the preferred path, 
we lost the preferred path link, as evidenced by the number of TCP retransmissions. 


sequence number 

I 10.0.2.7:33706 ==> 10.2.4.26:5002 (time sequence graph) 

3326000000 J 


3325000000 


3324000000 


3323000000 


3322000000 


3321000000 



15 : 30:40 15 : 31:00 15 : 31:20 15 : 31:40 15 : 32:00 15 : 32:20 

time 


Figure 1 1. Smooth Handoff From Nonpreferred to Preferred Path 


6. Summary 

We have described the mobile routing protocol and operation, the MR and some key configuration parameters. In 
addition, w'e provided a detailed description of the test network and the performance of transport protocols in 
dynamic routing environments. The results indicate that the current version of the MR code operates well, and 
handoffs are smooth between nonpreferred and preferred paths. In addition, the features available to manage 
handoffs can greatly improve performance, but they must be utilized judiciously with optimal settings varying 
between individual networks or network types. 
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